Create Backup Set

Backup Requirements

%edition_name% Requirements

Please ensure that the following requirements are met by the %edition_name%

  1. %edition_name% is installed on the Hyper-V server. For Hyper-V Cluster environments %edition_name% is installed on all Cluster nodes.
  2. The operating system account for setting up the Hyper-V / Hyper-V Cluster backup set must have administrator permission (e.g. administrative to access the cluster storage).
  3. %edition_name% user account has sufficient Hyper-V add-on modules or CPU sockets assigned. Hyper-V Cluster backup sets will require one %edition_name% license per node.
  4. Storage destination has sufficient quota assigned to accommodate the storage of the guest virtual machines.
    Hyper-V guest virtual machines contain three types of virtual disks:
    When %edition_name% backs up a Hyper-V guest virtual machines for an initial or subsequent full backup jobs:
  5. The default Java heap size setting on %edition_name% is 2048MB. For Hyper-V backups it is highly recommended to increase the Java heap size setting to improve backup and restore performance. (The actual heap size is dependent on amount of free memory available on your Hyper-V server). Delta generation of large VHD file is a memory intensive process, therefore, it is recommended to increase the Java heap size to be at least 4096MB. The actual required Java heap size is subject to various factors including files size, delta mode, backup frequency, etc.
  6. The temporary directory folder is used by %edition_name% for storing backup set index files and any incremental or differential delta files generated during a backup job. To ensure optimal backup/restore performance, it is recommended to be located on a local drive with plenty of free disk space but not on the Windows system C:\ drive. For Hyper-V 2008 R2, 2012, and 2012 R2, the temporary directory folder can only be set to local drive, and neither network or CSV path can be supported which is determined by the limitation of %edition_name% CBT service. Only Hyper-V 2016 supports local, network and CSV volumes for temporary directory folder.
  7. %edition_name% UI must be running when a guest virtual machine is started using Run Direct Restore or when migration process is running.
  8. For local, mapped drive, or removable drive storage destinations with Run Direct enabled, the compression type will always be set to No Compression and data encryption is disabled to ensure optimal backup and restore performance. The compression type and data encryption settings of backup set will only be applied to %cbs_name%, SFTP/FTP, or Cloud storage destinations.
  9. For ease of restore, it is recommended to back up the whole guest machine (all the virtual disks) rather than individual virtual disks.
  10. MS Windows system Backup is unable to create image of drives that are greater than 2TB on Windows 2008, 2008 R2 & 2011, due to the limitation of MS wbadmin using VHD format that is used in creating the image. The limitation in Windows 2012 has been increased to 64TB.
    For details, please refer to: https://support.microsoft.com/en-us/help/2696906/backup-fails-in-windows-7-when-trying-to-create-a-system-image
  11. Make sure NFS service has started for Run Direct to operate. If Run Direct is running on network drive, the login must have sufficient permission to access the network resources.

Hyper-V Server Requirements

Please ensure that the following requirements are met by the Hyper-V server

  1. The Hyper-V management tools are installed on the server. For Hyper-V Cluster environments, Hyper-V management tools is installed on all Cluster nodes.
  2. The Hyper-V services are started on the server. For Hyper-V Cluster environments the Hyper-V services are started on all Cluster nodes.
  3. The Microsoft Hyper-V VSS Writer is installed and running on the Hyper-V server and the writer state is Stable. This can be verified by running the vssadmin list writers command.
    vssadmin list writers
    Look for the script:
    Writer name: 'Microsoft Hyper-V VSS Writer' Writer Id: {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de} Writer Instance Id: {a51919e3-0256-4ecf-8530-2f600de6ea68} State: [1] Stable Last error: No error
  4. If Integration services is not installed / updated on a guest virtual machine or the guest operating system is not supported by Integration Services, the corresponding virtual machine will be paused or go into a saved state during the snapshot process for both backup and restore, and resume when the snapshot is completed. Furthermore, the corresponding virtual machine uptime will also be reset to 00:00:00 in the Hyper-V Manager.
  5. Installing or updating Integration Services guest virtual machine(s) may require a restart of the guest virtual machine to complete the installation.
  6. For Hyper-V 2008 R2 server in order to use Run Direct restore feature, the "Microsoft Security Advisory 3033929" security update must be installed.
    For details, please refer to: https://support.microsoft.com/en-us/kb/3033929
  7. For Run Direct Hyper-V Cluster backup sets, the storage destination must be accessible by all Hyper-V nodes.
  8. For Hyper-V Cluster backup sets, the guest virtual machines must be created and managed by the Failover Cluster Manager.

Hyper-V Backup Methods

%edition_name% v7 supports two methods for Hyper-V guest VM backup, VM Snapshot and Saved State.

  1. VM Snapshot
  2. The VM snapshot method is the preferred backup option, as it supports live guest VM backups. This means guest VM will not be put into a saved state when a VSS snapshot is taken during a backup job. So it will not affect the availability of any application or services running on the guest VM every time a backup job is performed.

    !

    If the VM Snapshot method cannot be used, %edition_name% will automatically use the Saved State method.

    VM Snapshot Method Requirements

  3. Saved State
  4. When the Saved State method is used, the guest VM is placed into a saved state while the VSS snapshot is created (effectively shut down), and the duration depends on the size of guest VM. The downside is it may affect the availability of any application or services running on the guest VM every time a backup job is performed.

CBT Requirement

Since %edition_name% version 7.9, a new service CBT Cluster Services (Ahsay Online Backup Manager) is installed and enabled upon installation / upgrade to version %edition_name% v7.9.0.0 or above.

Since %edition_name% v3.1.0.0, a new service CBT Cluster Services (CloudBacko Pro) is installed and enabled upon installation / upgrade to %edition_name% v3.1.0.0 or above.

  1. CBT (Changed Block Tracking) is used to optimize incremental backups of virtual machines by keeping a log of the blocks of data that have changed since the previous snapshot. When %edition_name% performs a backup, CBT feature can request transmissions of only the blocks that changed since the last backup, or the blocks in use.
  2. !

    From version 7.15.0.0 onwards, CBT service is supported on all the backup destinations for %edition_name% instead of only RunDirect related local destination.

  3. CBT cluster service is only installed on Windows x64 machine.
  4. Check if CBTFilter is enabled. This can be verified by running the net start CBTFilter command.
    C:\Users\Administrator>net start CBTFilter The requested service has already been started. More help is available by typing NET HELPMSG 2182.
  5. CBT Cluster Service and CBTFilter will NOT be installed on Windows Server 2016 where a built-in system called Resilient Change Tracking (RCT) will be used instead.

Windows Server 2016 Requirement

  1. RCT Requirement
  2. Guest VM Dependencies Requirements
  3. To get full use of Hyper-V, install the appropriate linux-tools and linux-cloud-tools packages to install tools and daemons, i.e. VSS Snapshot Daemon, for use with virtual machines.

    For details, please refer to: https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/supported-linux-and-freebsd-virtual-machines-for-hyper-v-on-windows

Limitations

The followings are the limitations of the MS Hyper-V backup module:

  1. Backup of guest machines located on a SMB 3.0 shares is not supported.
  2. Backup of virtual machine with pass through disk (directly attached physical disk) is not supported.
  3. For backup of individual virtual disk, the restored virtual machine does not support the reversion of previous snapshots, if the snapshot contains disks which are not previously backed up by %edition_name%.
  4. A guest virtual machine can only be restored to the Hyper-V server with the same version, i.e. backup of a guest on Hyper-V 2012 R2 server cannot be restored to Hyper-V 2008 R2 Server, and vice versa.
  5. The guest virtual machine will not start up if the virtual disk containing the guest operating system that is not restored.
  6. Restore of individual virtual disks is only supported using the Restore raw file option for a virtual disk with no snapshots.
    !

    This will require modification of Hyper-V guest configuration files, and this only should be done if you have in-depth knowledge and understanding of Hyper-V, otherwise the guest virtual machine may not startup properly.


  7. Restore to an Alternate location can only be performed on one guest virtual machine at a time.
  8. Restored guest virtual machines using Run Direct containing a saved state will not automatically power on. The saved state must be manually deleted in Hyper-V Manager and the guest must be powered on manually.
  9. For Run Direct enabled backup sets, the storage destination is restricted to Local, Mapped, or Removable Drive.
  10. When a guest virtual machine is started in a Run Direct instance being stopped, any changes made within the guest environment will be lost, if the guest virtual is not migrated to the Hyper-V Server using the "Auto migrate after Run Direct is running" option.
  11. When a guest virtual machine is started using Run Direct Restore, all backup jobs (manual, scheduled, and continuous) for the related backup set will be skipped.
  12. When a guest virtual machine is started using Run Direct Restore, the following features are not available for the backup set: Data Integrity Check, Space Freeing Up, or Delete Backup Data.
  13. Granular Restore is NOT supported on "Windows 7 SP1" or "Windows Server 2008 R2 SP1".

Granular Restore Requirements

Please ensure that the following requirements are met for Granular Restore to use:

  1. Granular restore is only supported on Hyper-V backup sets created and backed up using %edition_name% v7.13.0.0 or above on Windows platforms with Granular Restore feature enabled.
  2. Granular restore is only supported on Hyper-V backup sets created and backed up using %edition_name% v3.1.0.0 or above on Windows platforms with Granular Restore feature enabled.
  3. OpenDirect / Granular Restore add-on module is required per backup set for this feature to work. Contact your backup service provider for more details.
  4. Both compression and encryption are not enabled for Granular restore backup sets. To optimize restore performance the storage quota required will be higher than non-Granular Restore backup sets. Contact your backup service provider for details.
  5. Temporary Directory Folder should have at least the same available size as the backup image to be restored.
  6. One spare drive letter must be available for the Granular restore process as the VHD image is mounted on Windows as a logical drive by %edition_name% and it will automatically take the next available drive letter in alphabetical order for the mounted volume. (Drive letters A, B, and C will not be used.)
  7. Recommended minimum network speed is at least 100Mbits per second download speed. Network bandwidth should be increased in proportion to the guest virtual machine size and the incremental delta chain length to ensure optimal performance. Working with limited network bandwidth may severely affect the Granular restore performance. You can use an online speed connection testing site (e.g. http://www.speedtest.net) to test your connection speed.
  8. The following dependencies are restore related and therefore they will be checked by %edition_name% only when an Granular restore is performed. Absence of these elements will not affect the backup job but would cause the restore to fail.
  9. The Windows login account used for installation and operation of the %edition_name% client machine requires Administrator privileges

  10. Create a MS Hyper-V Backup Set

    Field Description
    Name This is the name of the backup set. You can create a meaningful name for it.
    Backup Type Select the backup set type from the drop down box.
    Version Select the version of the Hyper-V server.

    Steps:

    1. Type in a meaningful backup set name.
    2. Select the backup set type as MS Hyper-V backup.
    3. Select the correct version of the Hyper-V Server.
    4. Click [Next] button to continue.

    Setup example for MS Hyper-V cluster:

    Assumption:

    1. There are 3 nodes in the Hyper-V cluster setup, in the following example, we called it node1, node2 and node3.
    2. All the 3 nodes are located in the same timezone.
    3. They can connect to the same backup location, eg: a local shared destination with the same access permission.

    Notes:

    1. As the same backup set setting is needed to apply on all the machines when
      • the backup set is created or
      • any changes is applied to the backup set,
        eg:
        • change backup schedule
        • backup source selection
        • backup destination
        It is required to export the settings from the node with the last changes and then import to all other nodes. Otherwise, the backup set settings are not synchronized.
        eg:
        If the backup schedule is changed on node1, if the backup set is not synchronized, other nodes will keep running on an old backup schedule and may cause the backup job does not reflect to the actual servers status at the backup moment.
    2. When the settings is imported from other nodes, all the backup set settings on the node will be overwritten.

    Steps:

    1. Create/modify Hyper-V cluster backup set in node1, make sure the schedule backup is turned on.
    2. Export settings from node1 in [Utilities] > [Ex/Import Settings]
    3. Import the node1 settings into node2 in [Utilities] > [Ex/Import Settings]
    4. Enable the Schedule backup in node2.
    5. Export settings from node2 in [Utilities] > [Ex/Import Settings]
    6. Import the node2 settings into node3 in [Utilities] > [Ex/Import Settings]
    7. Enable the Schedule backup in node3.
    8. Export settings from node3 in [Utilities] > [Ex/Import Settings]
    9. Import the node3 settings into node1 and node2 in [Utilities] > [Ex/Import Settings]